There are good reasons for the management of the release of applications. Businesses see it as a safety-net to ensure the success of software deployment. This is a process that requires a different mind-set and set of disciplines to development, and is best handled by small specialist teams that are responsible for getting software delivered to its users in an enterprise. It is meticulous work, because users, and the businesses that employ them, judge software primarily by its resilience: They care a great deal if a release goes wrong and errors get into production systems.

Whereas the development cycle has speeded up greatly in the past decade, under the weight of new development techniques, and pressures from the business for new functionality, the same is not so true of release. Developers are often shocked and puzzled by the innate conservatism of the release Management process, but the application delivery process has to be meticulous enough to prevent errors getting into production systems. It has to deal with a wider range of platforms, including the Cloud, virtual servers, and mobile devices, and a more complex configuration.

This has led to a problem that has afflicted IT departments that have adopted the ideal of the rapid development cycle and Continuous Integration. How does one release applications to the users more quickly in line with the increased speed of development? Whereas one might think that it would require the same effort to manage a small number of changes in a large number of releases as the other way around; it doesn’t look that way to those of us who are tasked with release. A release is a release, no matter how numerous or complex the changes.

DevOps has never been presented as a nostrum. It doesn’t involve group rituals such as scrums and ‘post-its’ on the wall. (Rapid Development used to involve ‘shirtsleeves’, large felt-tips and A2 sheets fastened on the wall) It is more about Dev and Ops working in collaboration instead of seeing the opposite camp as being adversaries, defining the most effective workflows, and getting the processes reviewed and refined. All this means a much greater coordination.

At this point, automation of at least part of the release process becomes possible. There are prime candidates for automation, such as ‘hot-fixes’, data-center deployments, and configuration management. However, without the multi-department collaboration that is essential for the rapid delivery of applications, automation can have the danger of merely allowing mistakes to be made faster. The Automation process has to be scripted, maintained and controlled by the Ops and QA staff themselves, rather than being created only by developers. Whilst it is an essential component in the devOps initiative, it is secondary in importance to the cultural and organizational changes that often have to take place before continuous deployment or continuous delivery can become a reality.